Traditionally, with EDI, organizations have been empowered to send virtually limitless kinds of structured messages to one another to facilitate the communication of any kind of business data from one organization to another in automated ways. In this regard, once setup properly, EDI messages can be used to automate a variety of communications to and from partners, business sub-units, buyers, etc., thereby substantially reducing the overhead associated with filling out paper forms, storing volumes of papers, etc. With EDI, for instance, an organization merely fills out an electronic form in a manner conforming to a pre-defined schema, called a transaction set definition (TSD), and then the messaging, storage/record keeping and validation of the message(s) associated with the electronic form occurs automatically.
In current EDI messaging scenarios, which applies to both inbound messages (i.e., where a message is received by an organization) and to outbound messages (i.e., where a message is transmitted from an organization to an intended recipient of the message), a single message can be addressed for multiple parties, and multiple messages can be received from different parties. EDI messages can be represented in a native EDI compact file format, or as an extensible markup language (XML) file, and there are known ways of transforming from EDI flat files to XML representations, and vice versa. EDI data is transmitted as delimited files (without self describing tags) and therefore the encoding rules enforce very strict formatting rules to ensure destination application(s) are able to successfully parse and consume the information for down stream processing.
Today, XML Schema Definitions (XSDs), external data representations (XDRs) and document type definitions (DTDs) are typically used to represent schemas for EDI messages. In this regard, XSDs, XDRs and DTDs are schema files that can be created to describe TSDs, i.e., schemas for particular kinds of EDI messages. Today, these XSD, XDR and DTD files are stored as individual files that are used in connection with the validation of EDI messages in an EDI system.
Thus, EDI messages have an associated EDI TSD, which can be represented in a variety of formats. A TSD is a schema that instructs an EDI system how to interpret a given EDI message instance, i.e., how to validate an EDI message has been structured correctly and with appropriate information. For instance, when an EDI message of a particular type, e.g., a purchase order, is created in an EDI system, the EDI message should be created so that it conforms to the purchase order schema, and when an EDI message is received by another party, the schema is used to validate that the EDI message has been formed correctly. Sometimes, a party may additionally wish to edit an EDI message instance, however, the tools available for editing EDI message instances are currently inadequate.
In this regard, due to the cryptic nature of EDI encoding rules, generating valid instances of EDI documents remains challenging today because errors can be obscure to detect since the encoding rules by design compact data to a minimum amount of information that is difficult to read. For instance, FIG. 14 illustrates an exemplary instance 1410 of an EDI interchange displayed in a flat file editor UI 1400. Manual review of the EDI encoding to discover errors, or to edit an EDI element, can be difficult given the cryptic nature of the EDI encoding of instance 1410. For instance, finding bad data 1412 by hand would be extremely taxing. If more than a trivial number of instances are involved, such manual review is prohibitive.
An existing tool for EDI systems can be used to validate an instance of an EDI document against an associated TSD to determine whether it is a valid instance. Where the tool encounters an error based on review of the associated schema rules, the tool highlights the error, however, a user of such an editing tool must still consult the TSD to determine how to fix the error since the native EDI encoding is difficult to understand, i.e., merely highlighting bad data 1412 of interchange 1410 yields little information about how to correct the bad data 1412 to form a valid instance.
Accordingly, in consideration of the lack of sophistication of the current state of the art of the generation and modification of EDI documents based on EDI schemas in an EDI communications system, it would be desirable to provide improved tools for improved creation, editing, display and interaction with EDI instances relative to associated schemas in an EDI system. These and other deficiencies in the state of the art of EDI messaging will become apparent upon description of the various exemplary non-limiting embodiments of the invention set forth in more detail below.